3GPP defines an IP Multimedia Subsystem and, more specifically, the IP Multimedia Core Network Subsystem to enable support for IP multimedia applications. For the sake of simplicity, and since the IP Multimedia Subsystem is defined by 3GPP as being access-independent, all references are made throughout this specification to the IP Multimedia Subsystem (hereinafter IMS).
According to 3GPP, a user may register into the IMS network or receive a terminating call to experience IMS services. To this end, such user must be given a subscription to the IMS.
A user with an IMS subscription is given one or more Private User Identities. An IMS Private User Identity (hereinafter IMPI) is assigned by the home network operator, and is used for Registration, that is, for Authorization and Authentication into the IMS network. A user may also have one or more Public User Identities. An IMS Public User identity (hereinafter IMPU) is used by any user as a user's identifier for communications with other users.
Generally speaking, any IMPU of an IMS subscription may be shared by more than one IMPI within the same IMS subscription. In particular, an IMPU may be shared amongst all the IMPIs of an IMS subscription as stated in 3GPP TS 23.228. This feature is called IMPU sharing, and such IMPU is generally known under 3GPP as a ‘shared IMPU’.
In this respect, FIG. 1 illustrates an exemplary IMS subscription in accordance with 3GPP, wherein “Public User Identity—3” and “Public User Identity—4” are both shared by all the IMPIs of the IMS subscription, namely “Private User Identity—1” and “Private User Identity—2”, and are thus both considered ‘shared IMPUs’.
On the one hand, an IMS subscriber may register into the IMS network with an IMPI/IMPU pair selected by the IMS subscriber amongst those IMPIs and IMPUs associated in the IMS subscription of the IMS subscriber. The IMS subscriber thus registers into the IMS with a ‘Register’ message of a Session Initiation Protocol (hereinafter SIP), as defined by 3GPP, and including a selected IMPU/IMPI pair. Moreover, 3GPP further discloses a so-called ‘implicit registration set’ (hereinafter IRS) of more than one IMPU so that, where a given IMPU registered in an IMPI/IMPU pair is included in an IRS, all the IMPUs included in said IRS are considered to be registered as well.
On the other hand, 3GPP TS 24.229 Rel-7 introduces the concept of contact addresses into the IMS network. In this respect, the contact address can be defined as a SIP Uniform Resource Identifier (hereinafter a ‘SIP URI’) containing the IP address of the user equipment (hereinafter UE). Under certain circumstances, a contact address may also contain an instance identifier that uniquely identifies a specific UE amongst all other UEs registered with a same IMPU. For the sake of simplicity, this contact address may indistinctly be referred to as ‘contact address’ or simply as ‘contact’ throughout this specification.
A conventional registration process includes the submission of a ‘SIP Register’ message from the IMS subscriber towards a so-called Proxy Call Session Control Function server (hereinafter P-CSCF), which forwards such message towards an Interrogating Call Session Control Function server (hereinafter I-CSCF) of the IMS network where the destination subscriber belongs. In particular, this ‘SIP Register’ message includes a given IMPI/IMPU pair to be registered during this registration process, and a contact address associated with the currently used UE. The I-CSCF is in charge of selecting an appropriate Serving Call Session Control Function server (hereinafter S-CSCF) for serving the IMS subscriber, and queries a Home Subscriber Server (hereinafter HSS), which is in charge of subscription data for subscribers of the IMS network where the IMS subscriber belongs to, with the given IMPI/IMPU pair. Assuming that the IMS subscriber had not previously registered the IMPI/IMPU pair, the HSS returns the capabilities required for an S-CSCF to be assigned for serving the IMS subscriber. The I-CSCF receiving such capabilities selects an appropriate S-CSCF fulfilling the capabilities, and forwards the ‘SIP Register’ message with the IMPI/IMPU pair and the contact address thereto. The S-CSCF receiving the ‘SIP Register’ message submits its own registration towards the HSS to indicate it has been assigned for serving the subscriber identified by the IMPI/IMPU pair. The HSS then changes the status of said IMPI and IMPU from ‘not registered’ to ‘registered’, it stores a reference to the S-CSCF as being assigned for serving the IMS subscriber, and it downloads a user profile associated to said IMPU towards the S-CSCF. The S-CSCF receiving the user profile for the IMS subscriber and already having the given IMPI/IMPU pair and the contact address is now ready for serving the IMS subscriber.
At present, with the registration mechanism as described in 3GPP, a user is registered in the network with a given IMPU/IMPI pair and with a given contact address. However, where the user wants to register with another IMPI of the same IMS subscription or with another contact address, the same previous registration mechanism has to be repeated with said another IMPI or another contact address. Regarding the registration of contacts, when the user initiates a new registration attempt, the new contact traverses the network within the SIP header until the ‘SIP Register’ message arrives to the S-CSCF. The S-CSCF stores the contact bound to the IMPU received in the SIP message or to the IRS received from HSS during the registration process.
To somewhat alleviate this, the IMPU sharing concept, as described in 3GPP, allows an IMPU being shared by all the IMPIs of the same subscription, so that, a contact address associated with the shared IMPU can be shared by all the IMPIs of the IMS subscription.
In this respect, FIGS. 10A-10C illustrate how the S-CSCF builds up a data model based on the information received from successive registrations with the ‘SIP Register’ message and corresponding information received from the HSS. As illustrated in FIG. 10A, a user first registers with an IMPI-1, an IMPU-3, which is a shared IMPU as illustrated in FIG. 1, and with a contact address for the IMPI-1; and, since an implicit registration set IRS-2 of IMPUs is configured with IMPU-3 and IMPU-4, the S-CSCF builds up a data model associating the IMPI-1 with the IRS-2 and with the first contact address for the IMPI-1. Then, as illustrated in FIG. 10B, the user registers with a new IMPI-2, the same IMPU-3 and a first contact address for the IMPI-2; and the S-CSCF upgrades the data model associating both IMPI-1 and IMPI-2 with the IRS-2 and with the contact address for the IMPI-1 and the first contact address for the IMPI-2. Further, as illustrated in FIG. 10C, the user registers with the same IMPI-2 as in the latest registration, the same IMPU-3 and a second contact address for the IMPI-2; and again the S-CSCF upgrades the data model associating both IMPI-1 and IMPI-2 with the IRS-2 and with the contact address for the IMPI-1, the first contact address for the IMPI-2 and the second contact address for the IMPI-2.
This approach is still very inefficient since, generally speaking, the existing mechanism only allows the registration of one IMPI and one contact address in a single registration process. Moreover, the existing mechanism does not allow yet the registration of a shared IMPU from a given contact address, e.g. a home PC, and automatically enabling to receive terminating calls in another contact address, e.g. a mobile terminal.